Cloudfare patches to speed up LUKS encryption were upstreamed into linux kernel and backported to 5.10.9: cloudflare/linux#1 (comment)
Therefore, we bump to latest of 5.10.x (bump from 5.10.5 which doesn't contain the fixes)

Trace:
    sed -i 's/5.10.5/5.10.214/g' boards/*/*.config
    find ./boards/*/*.config | awk -F "/" {'print $3'}| while read board; do echo "make BOARD=$board linux"; make BOARD=$board linux; echo make BOARD=$board linux.save_in_oldconfig_format_in_place || make BOARD=$board linux.modify_and_save_oldconfig_in_place; done
    git status | grep modified | awk -F ":" {'print $2'}| xargs git add
    git commit --signoff

- Move patches from 5.10.5 -> 5.10.214
- Add linux kernel hash and version under modules/linux
- Change board configs accordingly

Signed-off-by: Thierry Laurion <[email protected]>

…LUKS containers (BTRFS QubesOS 4.2)

cryptsetup2 2.6.1 is a new release that supports reencryption of Q4.2 release LUKS2 volumes created at installation.
 This is a critical feature for the Qubes OS 4.2 release for added data at rest protection

Cryptsetup 2.6.x internal changes:
 - Argon2 used externally and internally: requires a lot of RAM and CPU to derivate passphrase to key validated in key slots.
  - This is used to rate limit efficiently bruteforcing of LUKS key slots, requiring each offline brute force attempt to consume ~15-30 seconds per attempt
  - OF course, strong passphrases are still recommended, but bruteforcing LUKSv2 containers with Argon2 would require immense time, ram and CPU even to bruteforce low entropy passphrase/PINs.
 - passphrase change doesn't permit LUKS key slot specification anymore: key slot rotates (new one consusumed per op: then old one wiped internally. EG: LUKS key slot 1 created, then 0 deleted)
 - reencryption doesn't permit old call arguments. No more direct-io; inadmissively slow through AIO (async) calls, need workarounds for good enough perfs (arguments + newer kernel with cloudfare fixes in tree)

cryptsetup 2.6.1 requires:
 - lvm2 2.03.23, which is also included in this PR.
   - requires libaio, which is also included in this PR (could be hacked out but deep dependency at first sight: left in)
   - requires util-linux 2.39
 - patches for reproducible builds are included for above 3 packages.

luks-functions was updated to support the new cryptsetup2 version calls/changes
 - reencryption happen in direct-io, offline mode and without locking, requiring linux 5.10.9+ to bypass linux queues
   - from tests, this is best for performance and reliability in single-user mode
 - LUKS container ops now validate Disk Recovery Key (DRK) passphrase prior and DRK key slot prior of going forward if needed, failing early.
  - Heads don't expect DRK to be in static key slot anymore, and finds the DRK key slot dynamically.
  - If reencrytipn/passphrase change: make sure all LUKS containers on same block device can be unlocked with same DRK
 - Reencryption: requires to know which key slot to reencrypt.
   - Find LUKS key slot that unlocks with DRK passphrase unlock prior of reencrypt call
 - Passphrase change: no slot can be passed, but key slot of DRK rotates.

kexec-seal-key
 - TPM LUKS Disk Unlock Key key slots have changed to be set in max slots per LUKS version (LUKSv1:7 /LUKSv2: 31)
  - If key slot != default LUKS version's keyslot outside of DRK key slot: prompt the user before wiping that key slot, otherwise wipe automatically
    - This takes for granted that the DRK key slot alone is needed on the system and Heads controls the LUKS key slots.
      - If user has something else going on, ie: Using USB Security dongle + TPM DUK, then the user will need to say no when wiping keys.
      - It was suggested to leave LUKS key slots outside of DRK alone, but then: what to do when all key slots would be used?
        - Alternative implementation could be to only prompt users to wipe keyslots other then DRK when key slots are all used (LUKSv1: 0-7, LUKSv2: 0-31)
          - But then cleanup would need to happen prior of operations (LUKS passphrase change, TPM DUK setup) and could be problematic.
  - LUKS containers now checked to be same LUKS version prior of permitting to set TPM DUK and will refuse to go forward of different versions.

TODO:
- async (AIO) calls are not used. direct-io is used instead. libaio could be hacked out
  - this could be subject to future work

Notes:
- time to deprecated legacy boards the do not enough space for the new space requirements
 - x230-legacy, x230-legacy-flash, x230-hotp-legacy
 - t430-legacy, t430-legacy-flash, t430-hotp-legacy already deprecated

Unrelated:
- typos fixes found along the way

Signed-off-by: Thierry Laurion <[email protected]>

…seems like luks passphrase change only happens on one of the containers; not all

Signed-off-by: Thierry Laurion <[email protected]>

… DEBUG for TOTP secret/qrcode output to console

Signed-off-by: Thierry Laurion <[email protected]>

… first LUKS volume, not all

Remove unneeded loop under luks_reencrypt

Signed-off-by: Thierry Laurion <[email protected]>

…wiped when going to recovery shell and upon automatic cleanup as all other secret

Signed-off-by: Thierry Laurion <[email protected]>

Signed-off-by: Thierry Laurion <[email protected]>

Signed-off-by: Thierry Laurion <[email protected]>

…ne last time: seems like luks passphrase change only happens on one of the containers; not all"

This reverts commit 20e9392.

To test this PR without reencryption, just 'git revert' this commit

Signed-off-by: Thierry Laurion <[email protected]>

…e changes

Signed-off-by: Thierry Laurion <[email protected]>

…1787 fixed the issue

Signed-off-by: Thierry Laurion <[email protected]>

Signed-off-by: Thierry Laurion <[email protected]>

…ith prompted DRK then ask user to confirm that those are all ok to reencryt/change passphrase onto (oem factory reset/manual, whatever)

- cache/reuse that passphrase, used afterward to find which LUKS keyslot contains the DRK, which is used to direct reencryption, also reused for passphrase change.
- refactoring detection + testing of prompted LUKS passphrase for discovered LUKS containers that can be unlocked with same passphrase to prompt user for selection

TODO: remove duplicate luks passphrase unlocking volumes functions for the moment

Signed-off-by: Thierry Laurion <[email protected]>

- fi misplaced
- rework reencryption loop
- added verbose output on TPM DUK key addition when LUKS container can be unlocked with DRK

Current state, left todo for future work:

TPM DUK:
- TPM DUK setup on defautl boot reuses /boot/kexec_key_devices.txt if present
- If not, list all LUKS partitions, asks user for selection and makes sure LUKS passphrase can unlock all
- Works on both LUKSv1 and LUKSv2 containers, reusing OS installer settings (Heads doesn't enforce better then OS installer LUKS parameters)

LUKS passphrase change/LUKS reencryption:
- Reuses /boot/kexec_key_devices.txt if existing
- If not, prompts for LUKS passphase, list all LUKS containers not being USB based and attempt to unlock all those, listing only the ones successfully unlocked
- Prompts user to reuse found unlockable LUKS partitions with LUKS passphrase, caches and reuse in other LUKS operations (passphrase change as well from oem factory reset/re-ownership)
- Deals properly with LUKSv1/LUKSv2/multiple LUKS containers and reencrypt/passphrase changes them all if accepted, otherwise asks user to select individual LUKS container

Tested on luksv1,luksv2, btrfs under luks (2x containers) and TPM DUK setup up to booting OS. All good

TODO:
- LUKS passphrase check is done multiple times across TPM DUK, reencryption and luks passphrase. Could refactor to change this, but since this op is done only one reencrypt+passphrase change) upon hardare reception from OEM, I stopped caring here.

Signed-off-by: Thierry Laurion <[email protected]>